本文同步發布於個人部落格

Junior 面試很常被問的一題是：「你有沒有寫過測試？」
多數面試者通常都會回答學過 (尤其是 jest)，但沒有真的實際在開發中寫過。
我覺得這無可厚非啦。
對於看得到畫面的前端來說，在測一個功能是否正常運作時，更多的是在畫面上那裡按按、這裡按按，然後看結果是否符合預期。
但為什麼面試這麼愛問這一題，一定有它的道理，對吧？
所以來說說：

前端到底需不需要寫測試？

前端到底需不需要寫測試？

In my opinion，前端當然需要寫測試。
但是多數情況是 nice to have。
有點矛盾，但請聽我娓娓道來。

如同前面所述，前端因為有畫面可以看，所以測試的需求不像後端那麼強烈。
但這指的是 component test 跟 E2E test 的需求沒那麼強烈，因為開發者會自己測、reviewer 也會跑起來測，之後 QA 跟 PM 也會測。
但有一種東西是強烈推薦前端在開發時就要寫的，那就是 unit test。

什麼東西需要 unit test？
以前端來說，我們通常會把函式封裝在 lib 和 composable 裡，代表的是一個獨立的、可複用的邏輯或流程。
舉例來說，我可能有個叫 useFormatResult 的 composable，它裡面封裝了數個專門對 api response 做格式化的函式。
我們在開發的時候，可能後端無法給我們所有可能的 response 真實回應，要知道，塞 mock data 到 DB 也是一件麻煩事，但這樣前端畫面上的測試是沒辦法涵蓋所有情況的。
我們不知道 useFormatResult 是否真的能 cover 所有的 response 格式，這時候就需要透過 unit test 來確保它的正確性。

透過 unit test 模擬各種情境，可以在開發 useFormatResult 的時候就知道它是否能 cover 所有情況。
玩過一點測試的應該對下面語法不陌生：

test('預期輸入 1 與 2 會得到 3', () => {
  expect(fn(1, 2)).toBe(3)
})

這是 jest，但 vitest 其實看起來跟他幾乎一樣，應該說前端的測試基本都長那樣：expect().toBe()。
就是你能預期這個正在測試的東西會得到什麼結果。
所以你只要設想夠多，以 useFormatResult 來說，假設後端已知會有 15 種結構，我是不是就可以寫 15 個 test case 來確保它都能正確處理？
這樣就不用後端真的要在 DB 裡面塞 15 筆不同格式的資料來測試了。

更需要 test 的例子是前端自己在做資料對齊、計算、轉換的時候。
這個流程通常在畫面呈現之前，要怎麼知道它是正確的？
一樣就是寫測試模擬各種情境，確保它在各種情況下都能得到正確結果。
最著名的就是正則表達式 (regex)，這東西你用肉眼去 review 根本很難看出它在幹嘛，歷史上有一些網路事件也是正則惹的禍。
所以對於正則，通常都是封裝成函式，然後寫一堆測試來確保它的正確性。

看起來寫測試很重要，但為何又說是 nice to have？

其實答案滿現實的，因為開發時程。

通常軟體開發的速度都很快，幾個週期內要交 XX 功能的事屢見不鮮。
在這種有時間壓力的情形，都會先追求「能動就好」。
測試就會傾向之後再補。

但這種情況只適用一般的功能。
對於那種真的很重要、很複雜，堪稱核心的功能，還是會要求邊開發編寫測試的。
舉例來說，前端要在 A 資料中找出 B 資料裡出現的項目，然後再做某種計算。
然後他可能會複用在很多頁面上，那這個函式就很重要，開發時就會要求要寫測試。
不過我得說啦，這種等級的函式其實沒那麼多，所以多數還是會先追求「能動就好」，走之後再補測試的路線。

總之，面試會問有沒有寫過測試，是因為測試對前端，應該說對整個軟體開發來說，都是一個很重要的環節。
只是前端通常因為看得到畫面以及一些如時程壓力等內部因素，讓很多公司或團隊沒那麼要求一定要寫測試。
但有寫一定不虧，所以推薦大家還是可以稍微了解一下怎麼寫測試。
前端的測試，如果不知道要玩哪套，就先無腦選 jest 吧！現在的測試基本長相都跟他差不多。